Securing SQL Server isn’t complicated, but it does require consistent attention to the areas where real risks arise, such as privileges, configuration, encryption, patching, and monitoring. This article outlines 15 practical, high-impact steps you can take to harden your SQL Server environment.
1. Use Low-Privilege Service Accounts
The SQL Server service, SQL Agent, SSIS, and other components should each run under their own low-privilege domain accounts.
Avoid using LocalSystem, LocalService, or Administrator.
Grant only the permissions required to access data/log directories and network shares.
2. Disable the sa Login
If possible, disable the ‘sa’ login.
If legacy constraints force it to exist, rename it if allowed and enforce strong password policies.
In general, prefer Windows or Entra-ID based authentication over SQL authentication.
3. Turn Off Unused Features
Each enabled feature increases the attack surface. Common candidates to disable include:
- SQL CLR (if not required)
- xp_cmdshell
- OLE Automation Procedures
- Ad Hoc Distributed Queries
- Cross-database ownership chaining
- SQL Browser (if named instance discovery isn’t required)
4. Keep SQL Server Patched
Apply patches regularly to:
- The SQL Server engine
- SQL components installed with SSMS
- .NET components on the server (if Windows)
- The server OS
Many published SQL Server vulnerabilities rely on unpatched systems – don’t let your system be one of them.
5. Enforce TLS Encryption
Require encrypted connections with force encryption = yes.
Install valid server certificates and disable older protocols such as TLS 1.0 and 1.1.
Use encrypted channels between availability replicas where possible.
6. Restrict Network Access
Use host-level or network firewalls to allow inbound access only from approved application servers.
Block unnecessary outbound connections.
Restrict the dedicated admin connection (DAC) to admin subnets.
7. Apply Least Privilege Inside the Database
Avoid using db_owner and/or sa for application accounts.
Instead, grant only the specific permissions required for the application’s operations.
Use roles rather than granting permissions directly, and separate schemas for application objects.
Avoid using built-in roles like db_datareader and db_datawriter. Whenever you assign permissions based on built-in roles, you end up often granting more permissions than are required. Instead, create user-defined roles, and assign appropriate permissions to them.
8. Enable Auditing
Turn on SQL Server Audit or lightweight login auditing. Record key events such as:
- Failed and successful logins
- Permission changes
- Role membership changes
- Schema changes
- Backup and restore activity
These logs are critical for both security investigations and compliance.
9. Encrypt Sensitive Data
Use a layered approach involving:
- Transparent Data Encryption (TDE): protects data and log files at rest
- Always Encrypted: provides end-to-end protection for specific columns
- Encrypted backups: prevent the most common data leak vector
- Avoid storing encryption keys inside the same database they protect.
10. Enforce Password and Login Policies
If SQL logins are required, enable password and lockout policies.
Disable or remove unused logins, and periodically check for orphaned or inactive accounts.
11. Configure Kerberos Correctly
Set service principal names (SPNs) for SQL Server services so that clients authenticate using Kerberos instead of falling back to NTLM.
This is especially important for:
- Linked servers
- Multi-tier applications
- Reporting Services (or Power BI Report Server) and Integration Services
Wherever possible, when working with Microsoft Azure or Azure-Arc, try to use system or user-assigned managed identities. SQL Server 2025 has expanded support in this area.
12. Secure Backup Storage
Backups often contain entire sensitive datasets. Keep them encrypted and stored in restricted locations.
Avoid leaving .bak or .trn files on shared or temporary directories.
Use separate credentials to access backup destinations.
13. Monitor and Baseline Activity
Monitor for unusual patterns such as:
- Spikes in failed logins
- Unexpected login or role changes
- Unusual schema modifications
- Large or unusual data exports
- Sudden tempdb or memory changes
Tools such as Extended Events, Query Store, SQL Server Audit, and Defender for SQL are useful here.
14. Harden the Operating System
SQL Server is only as secure as its operating system host.
Disable unused OS services, apply OS-level security controls, patch regularly, and restrict interactive logon access.
Avoid any web browsing or user applications on SQL Server machines.
15. Restrict Access to the Host
Use jump servers or bastion hosts for administrative access where possible. Only DBAs and system administrators should RDP into SQL Server hosts, and only if no other option is available.
Reduce the footprint of tools installed on the server.
Summary & Learn More
These 15 steps cover the areas that matter most in real SQL Server environments. No list is comprehensive but taken together, these steps reduce attack surface, improve auditing visibility, and safeguard both the engine and the data it manages.
For longer, more in-depth guides to SQL Server security, you may be interested in our SQL Server Security Primer (2023) and our 2019 Introduction to SQL Server Security series.
Load comments